this is a no brainer that provides the missing surface platforms and swap chain CreateSwapchainKHR that all vulkan and gl zink apps use.

 # termux GUI vulkan or GL?

  barring any termux GUI implementation for the actual android surface which I have yet to see. every single program ask for xlib surface and has no idea what the android surface is ... or that it even exists. there has to be one program somewhere that call the android surface without any java. perhaps ternux GUI guy knows. i have tried to ask him about it @tareksander

 # did anyone say GL

the bigger mystery is OpenGL. just completely lost at why everything is broken. only glmark glx manages to find a working configuration all other demos and apps fail for one reason or another

with angle the obvious omission is full non-es GL as in this output. all demos require the full GL specification

LD_LIBRARY_PATH=$P/opt/angle-android/gl eglinfo -v -p angle
    EGL_RENDERABLE_TYPE: opengles,opengles2
      EGL_SURFACE_TYPE: window,pbuffer

      by a horrendous roundabout it is possible to run it through a rendering host called virtual GL (? ? ?) and dosbox will actually NOT crash for the first time. although dosbox x crashes there too. and it is TEN times slower than the dosbox APK. which is exactly what I don't want in my life. GRADLE?!?! just puking over that thought. no standard output to terminal enormous build times for the smallest program just unbearable to work with

      so i will figure out open GL but it will take some time. the ES2 EGL demos SHOULD work angle specifically claims to have the required specifications . i might find flaws in mesa/demos but i think it is more likely a dispatch peoblem in core mesa or libglvnd . glx is proven to work in glmark-glx (slowly through zink) with ES (which i thought was impossible) but if egl  doesn't work natively that would be a blow out the driver is literally called egl. the driver for both Vulkan and GL is /vendor/lib64/egl/libGLES_mali.so and it doesn't support egl LoL? is that a joke.

      vkmark is the only app with comprehensible frame rates around two thousand fp or half a milli second for the vertex demos. all else has has thrash bin molasses drawing times that makes your grandma seem fast

      vkmark -b vertex
      [vertex] device-local=true: FPS: 2218 FrameTime: 0.451 ms

      glmark2 -b vertex
      FPS: 273 FrameTime: 3.674 ms

 ? ? ? what? ten times slower. and as mentioned ten times egl and es fail altogether to find any suitable config

  this build is only GLX and has ES (1 or 2?) support. not sure if the config advertise only es support

    glmark2 -d
      Debug: Found 84 matching FB configs.
      Debug: GLX chosen config ID: 0x163 Native Visual ID: 0x3f6
      Info:     GL_VERSION:     3.1 Mesa 24.3.4
   Debug: #if defined(GL_ES)

as a comparison cl produce a respectable 80 GFLOPS that should be able to run many things at descent speed if they only worked. i haven't looked at the java dosbox implementation or anything else to understand what they use. i suppose they have to use the ES subset. only NVIDIA provided the full GL specification. and the android surface is neither egl nor angle. perhaps? i am just not skilled enough to say

clpeak --compute-dp
  Device: Mali-G57 r0p1
    Half-precision compute (GFLOPS)
      half   : 40.65
      half2  : 79.84

the egl and es2 brethren fail in complete opposition to the expectation. the answer must be that mesa has zero testing on mobile platforms

glmark2-egl -d
glmark2-es2 -d
Debug: Using eglGetPlatformDisplayEXT()
dri2_dpy->fd_render_gpu >= 0" failed